home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 881 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.2 KB
  1. Path: nntp-trd.UNINETT.no!lolsen
  2. From: lolsen@hsr.no (Lasse Olsen)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: Hombre history - RISC selection
  5. Date: 10 Jan 1996 11:50:05 GMT
  6. Organization: UNINETT news service    
  7. Distribution: world
  8. Message-ID: <4d095d$5at@dole.uninett.no>
  9. References: <john.hendrikx.44pj@grafix.xs4all.nl>
  10. NNTP-Posting-Host: gorina7.hsr.no
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. John Hendrikx (john.hendrikx@grafix.xs4all.nl) wrote:
  14. : In a message of 06 Jan 96 Michael Van Elst wrote to All:
  15.  
  16. :  >> No really?  I'm glad you brought this to my attention.  Next you'll be
  17. :  >> telling me that HAM8 is also better than '23-bit' screens as it is
  18. :  >> -possible- to use the full 24-bit palette with HAM8 (if the picture was
  19. :  >> large enough).
  20.  
  21. :  MVE> I am telling you that it is better than 16bit. Nothing more. With HAM
  22. :  MVE> you get some degree of fringing, with 16bit you get larger visible
  23. :  MVE> quantization errors. Both deficiencies cause about the same amount of
  24. :  MVE> image degradation.
  25.  
  26. : Fringing is much worse than a simple quantization error.  
  27.  
  28.     For some types of graphics, true, but my experience have
  29.     shown me that ham8 is, for the most part, more suited to
  30.     typical truecolor work.
  31.     This is especially evident in animation.
  32.  
  33. : HAM8 actually causes
  34. : pixels which have wrong colors (wrong HUE) and wrong brightness.
  35.  
  36. :  An example of wrong HUE and brightness:
  37.  
  38. : TrueColor data: $ff ff ff  $e9 e9 e9
  39.  
  40. :   HAM displays: $ff ff ff  $ff e9 ff
  41.  
  42. : Not only is the color too bright, it also isn't gray anymore as it should be.
  43. : This kind of errors happen all the time with HAM.  With 16-bit the result will
  44. : atleast be consistent (no ugly pixels in places messing up the whole pic) and
  45. : the errors will never exceed a certain limit (the error will never be more than
  46. : $04 02 04 -- try getting that with HAM8)
  47.  
  48.     But, this isn't much of a problem and can even be simulated by 
  49.     ham to a degree. The viewer will not notice the difference at 
  50.     all on a normal screen.
  51.     Banding with 16-bit really looks much worse.
  52.     And, in a worst-case scenario you'd have maybe one or two pixles
  53.     with the wrong settings, only to be corrected and surrounded by
  54.     correct samples.
  55.  
  56.     Ex: $255 000 000 changes to $000 000 255 in maximum two steps.
  57.  
  58. :  >> giving better results.  Try dithering HAM from right to left for example
  59. :  >> -- next to impossible, but with 'normal' displays this can make quite a
  60. :  >> difference.
  61.  
  62. :  MVE> Does it ? :)
  63.  
  64. : Yes, if you dither all odd lines from left to right and even lines right to
  65. : left the dithering will be better.  If you only draw the lines from left to
  66. : right (in HAM you're forced to do this) then the quantization errors will
  67. : slowly shift to the right of the picture.
  68.  
  69.     In theory, yes - in practise, hardly. 
  70.     By having the 24-bit palette as an initial referance the 
  71.     shifting will be minimal and again this depends on what type 
  72.     of graphics you are looking at.
  73.     The point is moot anyway as you wont attempt to dither with Ham8.
  74.  
  75. :  >> (just think of it; if we had 16-bit screens for 4 years now instead of
  76. :  >> HAM8, it would have meant that v39 graphics library would already have
  77. :  >> support for true color screens (which is basicly one of the biggest things
  78. :  >> missing in the current graphics library...))
  79.  
  80. :  MVE> Which is a completely different issue. graphics doesn't support HAM8
  81. :  MVE> rendering either. So what ?
  82.  
  83. : HAM8 is simply not supported as it is impossible to use a display mode 
  84. : like HAM for graphics rendering.  
  85.  
  86.     Ham8 is well suited for displaying, only not very well suited 
  87.     for rendering. If you do a render in 24-bit and display it in
  88.     Ham8 however, the results are fine.
  89.  
  90. : Even doing a simple thing like drawing a line gives
  91. : enormous problems.  C= surely would have made graphics use 16-bit if it was
  92. : available instead of HAM.
  93.  
  94.     Probably both. This was, and is, a bandwidth issue.
  95.     C= even had a Ham10 mode ready in AAA even though it already
  96.     had full 24-bit support.
  97.  
  98. :  >> HAM (Hold And Modify):
  99. :  >>  a hack to display more colors because the OS and Hardware are
  100. :  >>  unable to handle the real thing.
  101.  
  102. :  MVE> The real thing is a 24bit display, not a 16bit one.
  103.  
  104. : The real thing for me is a Chunky True Color screen, and 16-bit fits that
  105. : description.
  106.  
  107.     So, you prefer 16-bit (high-color) to 24-bit (true-color)? ;)
  108.     Cheers...
  109.